HTTP/1.1 vs HTTP/2 核心原理与性能对比
核心要点
- HTTP/1.1：默认开启 Keep-Alive，但受限于 TCP 连接数（通常 6 个） 和 应用层队头阻塞，性能存在瓶颈。
- HTTP/2：引入 二进制分帧 和 多路复用，彻底解决应用层队头阻塞，大幅提升并发性能。
- HTTP/3：基于 UDP/QUIC，解决 TCP 层队头阻塞，实现真正的全链路并发。
一、图解原理：从串行到并发
1. 连接方式对比
在 HTTP/1.1 中，浏览器为了提升并发，通常会针对同一域名开启最多 6 个 TCP 连接。而 HTTP/2 则通过一个 TCP 连接实现全并发传输。
2. HTTP/1.1 的顽疾：应用层队头阻塞
即使开启了 Keep-Alive，HTTP/1.1 在同一个 TCP 连接上仍然是 串行 的：必须等待前一个响应返回，才能发送下一个请求。如果前一个响应由于各种原因延迟（如服务器处理慢、大图传输），后续请求都会被阻塞。
3. HTTP/2 的良药：多路复用（Multiplexing）
HTTP/2 引入了 二进制分帧层（Binary Framing）。它将请求 and 响应拆分为更小的“帧（Frame）”，并为每个帧标记 流 ID（Stream ID）。
- 并发传输：不同请求的帧可以交错发送，不再需要排队。
- 数据重组：接收端根据流 ID 重新拼装，还原为完整的报文。
二、核心深度对比
| 维度 | HTTP/1.1 | HTTP/2 (核心改进) |
|---|---|---|
| 数据格式 | 文本格式：解析效率低，容易出错 | 二进制格式：分帧传输，解析高效，更安全 |
| 连接模型 | 多 TCP 连接：握手开销大，慢启动限制性能 | 单一 TCP 连接：长连接复用，规避握手 and 慢启动 |
| 请求方式 | 串行请求：存在应用层队头阻塞（HOL） | 多路复用：真正实现请求/响应的完全并发 |
| 首部压缩 | 无/Gzip：重复发送大量冗余头部字段 | HPACK 算法：静态/动态字典，大幅减小头部体积 |
| 服务端推送 | 不支持：只能由客户端主动请求 | Server Push：服务器可主动推送 JS/CSS 到缓存 |
三、HTTP/2 是否完美？（TCP 层的阻碍）
虽然 HTTP/2 解决了 应用层 的队头阻塞，但它仍然基于 TCP 协议。
- TCP 层队头阻塞：TCP 必须保证数据的顺序交付。如果网络发生丢包，即使后续包已到达接收端，TCP 协议栈也会卡住，等待重传。
- 后果：在网络质量较差的情况下，HTTP/2 的单一连接会导致 所有 Stream 瞬间卡死。
四、进化：HTTP/3 彻底终结阻塞
HTTP/3 放弃了 TCP，转而基于 UDP 协议实现的 QUIC 协议。
- 独立流控：每个 Stream 拥有独立的序列号，一个 Stream 丢包不影响 other Stream。
- 0-RTT 建连：结合 TLS1.3，大幅缩短首字节时间（TTFB）。
五、面试通关：标准回答
面试官：请对比一下 HTTP/1.1 和 HTTP/2 的区别？
标准回答：
- 核心差异在于多路复用：HTTP/1.1 虽然有持久连接，但在一个连接内是串行处理的，存在应用层队头阻塞。而 HTTP/2 通过二进制分帧层，将请求拆分为帧并标记流 ID，实现了在同一个 TCP 连接上的交错并发传输，解决了阻塞问题。
- 数据格式：HTTP/1.1 是基于文本的，而 HTTP/2 采用二进制分帧，解析更高效且抗干扰能力强。
- 首部压缩：HTTP/2 使用 HPACK 算法压缩头部，利用静态/动态字典减少了重复头部的传输体积。
- 性能对比：HTTP/2 只需要一次握手，且能充分利用带宽，在多资源加载场景下（如现代网页）通常比 1.1 快 30% 以上。
- 缺陷：HTTP/2 仍受限于 TCP 层的队头阻塞，当发生丢包时，性能可能退化。这也是 HTTP/3 采用 UDP/QUIC 协议的主要原因。
六、总结一句话
- HTTP/1.1：多连接串行，卡在“排队” 🚫
- HTTP/2：单连接并发，卡在“丢包” ⚠️
- HTTP/3：UDP/QUIC 全并发，快如“疾风” ✓